The present invention relates to computer networks and, more particularly, to management of entities in a mixed Advanced Peer to Peer Networking (APPN) and Data Link Switching (DLSW) computer network.
Data communications in a computer network involves the exchange of data between two or more entities interconnected by communication links and subnetworks. These networks are typically software programs executing on hardware computer platforms which, depending on their roles within a network, may serve as host stations, end stations or intermediate stations. Examples of intermediate stations include routers, bridges and switches that interconnect communication links in subnetworks; an end station may be a computer located on one of the subnetworks. More generally, an end station connotes a source of or target for data that typically does not provide routing or other services to other computers on the network. A local area network (LAN) is an example of a subnetwork that provides relatively short-distance communication among the interconnected stations; in contrast, a wide area network (WAN) facilitates long-distance communication over links provided by public or private telecommunications facilities.
End stations typically communicate by exchanging discrete packets or frames of data according to predefined protocols. In this context, a protocol represents a set of rules defining how the stations interact with each other to transfer data. Such interaction is simple within a LAN, since these are typically xe2x80x9cmulticastxe2x80x9d networks: when a source station transmits a frame over the LAN, it reaches all stations on that LAN. If the intended recipient of the frame is connected to another LAN, the frame is passed over a routing device to that other LAN. Collectively, these hardware and software components comprise a communications network and their interconnections are defined by an underlying architecture.
Most computer network architectures are organized as a series of hardware and software levels or xe2x80x9clayersxe2x80x9d within each station. These layers interact to format data for transfer between, e.g., a source station and a destination station communicating over the network. Specifically, predetermined services are performed on that data as it passed through each layer, and the layers communicate with each other by means of the predefined protocols. This design permits each layer to offer selected services to other layers using a standardized interface that shields the other layers from details of actual implementation of the services. The lower layers of these architectures are generally standardized and implemented in hardware and firmware, whereas the higher layers are usually implemented in the form of software. Examples of such communications architectures include the System Network Architecture (SNA) developed by International Business Machines (IBM) Corporation and the Internet Communications Architecture.
The Internet architecture is represented by four layers termed, in ascending interfacing order, the network interface, internetwork, transport and application layers. The primary internetwork layer protocol of the Internet architecture is the Internet Protocol (IP). IP is primarily a connectionless protocol that provides for internetworking routing, fragmentation and reassembly of exchanged packets-generally referred to as xe2x80x9cdatagramsxe2x80x9d in an Internet environment-and which relies on transport protocols for end-to-end reliability. An example of such a transport protocol is the Transmission Control Protocol (TCP), which is implemented by the transport layer and provides connection-oriented services to the upper layer protocols of the Internet architecture. The term TCP/IP is commonly used to denote this architecture; the TCP/IP architecture is discussed in Computer Networks, 3rd edition, by Andrew S. Tanenbaum, published by Prentice-Hall, PTR in 1996, all disclosures of which are incorporated herein by reference, particularly at pages 28-54.
SNA is a communications framework widely used to define network functions and establish standards for enabling different models of IBM computer to exchange and process data. SNA is essentially a design philosophy that separates network communications into several layers termed, in ascending order, the physical control, the data link control, the path control, the transmission control, the data flow control, the presentation services and the transaction services layers. Each of these layers represents a graduated level of function moving upward from physical connections to application software.
In the SNA architecture, the data link control layer is responsible for transmission of data from one end station to another. Bridges or devices in the data link control layer that are used to connect two or more LANs so that end stations on either LAN are allowed to access resources on the LANs. Connection-oriented services at the data link layer generally involve three distinct phases: connection establishment, data transfer and connection termination. During connection establishment, a single path or connection, e.g., an IEEE 802.2 logical link control type 2 (LLC2) or xe2x80x9cdata link controlxe2x80x9d (DLC) connection, is established between the source and destination stations. Once the connection has been established, data is transferred sequentially over the path and, when the LLC2 connection is no longer needed, the path is terminated. Reliable communication of the LLC2 (DLC) is well known and described by Andrew Tanenbaum in his book Computer Networks, Second Edition, published in 1988, all disclosures of which are incorporated herein by reference, especially at pages 253-257.
FIG. 1 is a schematic block diagram of a conventional computer network 100 having a host computer coupled to a Token Ring (TR) network TR1 and an end station coupled to TR2. The TR networks are of the type that support Source/Route Bridging (SRB) operations with respect to the contents of a routing information field (RIF) of a frame. The host computer is preferably a SNA host entity comprising a host mainframe computer 110 coupled to a channel-attached router or front end processor (FEP), hereinafter referred to as the xe2x80x9chost network connectionxe2x80x9d 112; in addition, the end station is an SNA entity 114 comprising a xe2x80x9cphysical unitxe2x80x9d (PU), i.e., a component that monitors the station""s resources, and a xe2x80x9clogical unitxe2x80x9d (LU) which consists of logical services by which a user may access the SNA network. An SRB bridging device B1 interconnects TR1 and TR2 such that the SRB network 100 effectively functions as a LAN.
The PU entity communicates with the host by exchanging TR frames over LLC2 connections or sessions through the SRB network. Each TR frame 120 includes a RIF 122 that contains source route information in the form of ring number/bridge number pair xe2x80x9chopsxe2x80x9d within a path between the stations. For example, the RIF 122 of TR frame 120 transmitted by the PU to host contains [0021.0010]. An LLC2 session is established between the stations using a special TR frame, called an explorer frame.
The explorer frame is used by a source (PU) to xe2x80x9cdiscoverxe2x80x9d the path to a destination (host); thereafter, a Set Asynchronous Balanced Mode Extended (SABME) frame is sent from the PU to the host to establish a logical connection between the end stations, and the host responds to the SABME frame with an Unnumbered Acknowledgment (UA) frame. Once the UA frame is received by the PU, a connection is established between the source and destination, and these stations communicate by exchanging TR information (INFO) and acknowledgment frames until the logical link SNA session is completed.
For example, the PU transmits an INFO frame over TR2 and through BRI and TR1 to the host. Upon successfully receiving the INFO frame, the host responds by transmitting an LLC2 Receive/Ready (RR) acknowledgment frame over the SRB network to the PU. This INFO/RR exchange continues until the PU has successfully transmitted all of its data and the host has successfully received all of that data. Session completion is then initiated by a Disconnected Mode (DM) frame being transmitted from the PU to the host; the disconnection is thereafter acknowledged by the host responding with a UA frame. The LLC2 frames (packets) are described by Radia Perlman in her book Interconnections, Bridges and Routers, published by Addison Wellesly Publishing Company, in 1992, all disclosures in which are incorporated herein by reference, particularly at pages 33-34.
In a SNA network, applications executing on end stations typically access the network through LUs of the stations; accordingly, in a typical SNA network, a communication session may connect two LUs in a LUxe2x80x94LU session. Activation and deactivation of such a session is addressed by Advanced Peer to Peer Networking (APPN) functions. The APPN functions generally include session establishment and session routing within an APPN network. FIG. 2 is a schematic block diagram of an APPN network 200 comprising two end stations, which may be configured as a host network connection entity 202 and a PU entity 212, coupled to token ring (TR) LANs TR1-2, respectively. During session establishment, an end station (such as PU 212) requests an optimum route for a session between two LUs; this route is calculated and conveyed to PU 212 by an intermediate station (e.g., station 216) via a LOCATE message exchange through the network 200. Thereafter, a xe2x80x9cset-upxe2x80x9d or BIND message is forwarded over the route to initiate the session. The BIND includes information pertaining to the partner LU requested for the session.
Intermediate session routing occurs when the intermediate stations 206, 216, configured as APPN network nodes (NN), are present in a session between the two end nodes. As can be seen, the APPN network nodes are further interconnected by a WAN 210 that extends the APPN architecture throughout the network. The APPN network nodes forward packets of an LUxe2x80x94LU session over the calculated route between the two APPN end nodes. An APPN network node is a full-functioning APPN router node having all APPN base service capabilities, including session services functions. An APPN end node, on the other hand, is capable of performing only a subset of the functions provided by an APPN network node. APPN network and end nodes are well-known and are, for example, described in detail in Systems Network Architecture Advanced Peer to Peer Networking Architecture Reference IBM Doc SC30-3422 and APPN Networks by Jesper Nilausen, printed by John Wiley and Sons, 1994, at pgs 1-83.
FIG. 3 is a schematic block diagram of the software architecture of an APPN node 300. As noted, application 302 executing on an APPN end node communicates with another APPN end node through a LUxe2x80x94LU session; LU 304 within each end node functions as both a logical port for the application to the network and as an end point of the communication session. The session generally passes through a path control module 312 and a data link control (DLC) module 316 of the node, the latter of which connects to various network transmission media. A control point (CP) module 308 coordinates performance of all APPN functions within the node 300 and, in the case of an APPN network node, is in session with a CP in adjacent APPN network nodes. Through these CPxe2x80x94CP sessions, all network nodes in an APPN environment coordinate operation of the network, and exchange, inter alia, configuration information. By interfacing with a configuration database 310, the CP coordinates management of the actual data communication links (DLC) in the network.
When functioning as an APPN router node, such as NN 206, an intermediate session routing (ISR) module 305 maintains a portion of the session in each xe2x80x9cdirectionxe2x80x9d with respect to an adjacent network node, such as NN 216 of network 200. In response to receiving the BIND message during session establishment, path control 312 and ISR 305 are invoked to allocate resources for the session. In particular, each entity 206, 216 allocates a local form session identifier for each direction of the session. Collectively, each of these individually-established xe2x80x9clocalxe2x80x9d sessions form the logical communication session between the LUs 304 of the end node entities 202, 212.
The APPN router node may provide Dependent LU Requester (DLUR) services on behalf of the PU (xe2x80x9cdependentxe2x80x9d LU) in network 200 while the host network connection 202 may provide Dependent LU Server (DLUS) services. As described herein, the DLUS host is coupled to the DLUR router by way of a xe2x80x9cpipexe2x80x9d connection over which control traffic for the dependent session flows. The DLUR router essentially functions as a xe2x80x9csurrogatexe2x80x9d for the downstream PU with respect to the DLUS host such that the control information flows over the network to the PU by way of the DLUR router.
Data Link Switching (DLSw) is a mechanism for forwarding SNA protocol frames over, e.g., a TCP/IP backbone WAN such as the Internet. In traditional bridging, the data link connection is end-to-end, i.e., effectively continuous between communicating end stations. A stream of data frames originating from a source station on a source LAN traverses one or more bridges specified in the path over the LLC2 (DLC) connection to a destination station on a destination LAN. In a network implementing DLSw, by contrast, the LLC2 connection terminates at a local DLSw device entity, e.g., a router. An example of a DLSw network arrangement may comprise a host DLSw router connected to a host computer via a host LAN and a remote DLSw router connected to a remote LAN having a destination station. The LANs that are accessed through the DLSw routers may appear as SRB subnetworks attached to adjacent rings; each of these adjacent rings manifest as a virtual ring within each DLSw router that effectively terminates the SRB network.
A DLSw network is formed when two DLSw devices interconnect the end nodes of the APPN network by way of the IP network; the DLSw devices preferably communicate using a Switch-to-Switch protocol (SSP) that provides packet xe2x80x9cbridgingxe2x80x9d operations at the LLC (i.e., DLC) protocol layer. FIG. 4 is a schematic block diagram of a DLSw network 400 having a TCP/IP cloud 410 disposed between host and remote SRB subnetworks 420, 430. Each SRB subnetwork comprises a DLSw router 1, 2 coupled to the host network connection 402 and PU/LU 412 via TR1 and 2, respectively. The DLSw routers function as end points between TCP sessions over the TCP/IP cloud when transporting TR frames associated with DLC sessions over that intermediate network.
Broadly stated, each DLSw router establishes a xe2x80x9cpeer relationshipxe2x80x9d to the other DLSw router in accordance with a conventional capabilities exchange message sequence, and the logical and physical connections between these routers connect the subnetworks into a larger DLSw network. To establish a peer connection in accordance with an implementation of DLSw switching, the host DLSw router first opens logical TCP (Read/Write) xe2x80x9cpipexe2x80x9d connections to the remote DLSw router using a conventional socket technique to create a socket into the transport layer of the protocol stack. Once the TCP pipes are established, the SSP protocol is used to transport the capabilities exchange messages between the two DLSw routers.
The capability exchange messages contain various parameters, such as the number of pipes used for communicating between the DLSw routers and the largest frame size supported by the routers. Each DLSw router responds to each capability exchange message issued by its peer router with a capability exchange response message. Upon completion of the exchange, each router reconfigures itself to xe2x80x9cact uponxe2x80x9d the agreed capabilities and the peer connection is established. Establishment of a peer connection can occur automatically upon xe2x80x9cboot-upxe2x80x9d of each DLSw router; that is, as soon as a DLSw router activates, it connects with its DLSw peer. The DLSw forwarding mechanism is well known and described in detail in Request For Comment (RFC) 1795 by Wells and Bartky, 1995 at pgs 1-91.
Upon receiving a TR frame from a source on the host SRB subnetwork that is destined for a destination on the remote subnetwork, the host DLSw router employs the SSP protocol to communicate with its DLSw peer router by forwarding the native TR frame over the TCP/IP network to the remote SRB subnetwork. That is, the TR frame received at the host DLSw router from the source is encapsulated within a SSP protocol frame and forwarded over the TCP/IP cloud to the remote DLSw router. The source route information contained in the RIF of each TR frame terminates inside the virtual ring of the DLSw router; notably, the RIF information is locally stored at the DLSw router.
The host DLSw router then multiplexes the LLC2 session data stream over a conventional TCP transport connection to a remote DLSw router. LLC2 acknowledgment frames used to acknowledge ordered receipt of the LLC2 data frames are xe2x80x9cstripped-outxe2x80x9d of the data stream and acted upon by the host DLSw router; in this way, the actual data frames are permitted to traverse the IP cloud to their destination while the xe2x80x9coverheadxe2x80x9d acknowledgment frames required by the LLC2 connections for reliable data delivery are kept off the cloud. The LLC2 connections from the source LAN to the host transmitting DLSw router, and from the remote receiving DLSw router to the destination LAN, are entirely independent from one another. Data link switching may be further implemented on multi-protocol routers capable of handing DLSw devices as well as conventional (e.g., SRB) frames.
DLSw routers can establish multiple parallel TCP sessions using well-known port numbers. All frames associated with a particular LLC2 connection typically follow a single designated TCP session. Accordingly, SNA data frames originating at the PU are transmitted over a particular LLC2 connection along TR2 to DLSw2, where they are encapsulated within a designated TCP session and transported over the TCP/IP cloud 410. The encapsulated messages are received by DLSwl, decapsulated to their original frames and transmitted over a corresponding LLC2 connection of TR1 to the host in the order received by DLSw2 from the PU.
The LLC2 connection between the PU and host is identified by a data link identifier (ID) 460 consisting of a pair of attachment addresses associated with each end station. Each attachment address is represented by the concatenation of a media access control (MAC) address (6 bytes) and a LLC service access point (SAP) address (1 byte). Specifically, each attachment address is classified as either a target address comprising a destination MAC (DMAC) and a destination SAP (DSAP), or an origin address comprising a source MAC (SMAC) and source SAP (SSAP) addresses. The attachment addresses are contained in the TRs frame exchanged between the PU and host entities.
Furthermore, the designated TCP session is identified by a pair of circuit IDs 470, each comprising a 64-bit number that identifies the LLC2 circuit within a DLSw circuit. The DLSw circuit ID generally comprises a data link circuit port ID (4 bytes) and a data link correlator (4 bytes). A pair of circuit IDs along with a data link ID uniquely identifies a single end-to-end circuit through the network. Notably, each DLSw router maintains a table 450 comprising a plurality of data link ID and corresponding DLSw circuit ID pair entries. In order to associate LLC2 frame traffic with a corresponding DLSw circuit when communicating over the IP cloud, each DLSw router typically indexes into the table (the xe2x80x9cDLSw tablexe2x80x9d) using a data link ID to find the corresponding DLSw circuit IDs.
The DLSw circuit information described above, including the data link IDs, are available to a network operator of a network management station (NMS) 480 via a Simple Network Management Protocol (SNMP) configured to access DLSw management information base (MIB) tables within the routers. The MIB and SNMP protocol, and their use in providing network management information between SNMP management stations and agents are well-known and described in, e.g., SNMP, SNMPv2 and RMON by William Stallings, printed by Addison Wesley Publishing Company, 1996.
The orientation of the MAC/SAP attachment addresses of the data link IDs acquired from each router is dependent on the proximity of the SNA entity to which the router is connected. For example, the remote DLSw router identifies the PU MAC/SAP attachment address as origin and the host network connection MAC/SAP attachment address as target, whereas the host DLSw router identifies the PU and host connection addresses in reverse order. The DLSw routers do not, however, maintain the name of the PU, which is a common way for an operator to identify a session.
A problem involving a PU session in the network 400 may be diagnosed by the network operator using a conventional approach that correlates SNA frame traffic sessions to DLSw routers for a network having a peer connection over an IP cloud between DLSw peer routers. Typically, management of the SNA entities takes place on the host in accordance with a network management application program, such as NetView, executing on the host. The application can access the status of the PU and LU entities by virtue of their definitions contained in a specialized data structure 490 of the host network connection 402. This data structure is a virtual telecommunication access method (VTAM) table 490 having entries whose contents define all the PUs and LUs with respect to the host. The content definitions of the entries comprise a name (e.g. PU name 492) along with a block number and ID number (IDBLK/IDNUM 494) that uniquely identifies each PU on a network at a given time.
The NetView application manages those SNA resources known to it; as used in this context, the term xe2x80x9cmanagingxe2x80x9d means that the application program can check and change the status of the resources, and can further control those resources to acquire, e.g., information leading to the traffic patterns of the resources. However, the NetView application cannot manage the component in the routers that encapsulate SNA traffic. As noted, the DLSw routers are preferably managed by the SNMP tool executing on the NMS which communicates with SNMP agents resident on the routers.
According to the conventional approach, the NMS communicates with an SNMP agent in each DLSw router to acquire DLSw MIB information including a data link ID identifying a DLSw circuit associated with the router. Since the host computer xe2x80x9cownsxe2x80x9d SNA sessions in the network, it maintains SNA-specific information (in addition to the PU name) such as the MAC/SAP addresses 496 for the host network connection and the PU on VTAM 490 in the host. The NMS issues commands to the host over a pipe connection 485 to retrieve the SNA-specific information from VTAM. The SNA-specific information retrieved from VTAM 490 does not, however, include information with respect to the DLSw routers that are routing the session traffic.
In response to a query from the operator specifying a PU name of the session, the NMS compares the MAC/SAP addresses retrieved from VTAM with the data link IDs in the MIBs to identify a DLSw circuit at each router. The NMS then uses the orientation of the MAC/SAP attachment addresses from the routers to distinguish between the host and remote DLSw routers. Thereafter, the NMS can draw the topology of the DLSw network, including the DLSw circuit and PU session path, to isolate any failures in the network.
However, if the session path traverses a heterogeneous network having both DLSw and APPN devices, correlation cannot be done efficiently using the conventional approach primarily because the host (VTAM) does not store the MAC/SAP address information of the PU in such a mixed APPN/DLSw network. That is, the host xe2x80x9cseesxe2x80x9d a 5 logical connection between its DLUS service and the DLUR service terminating at the APPN router; accordingly, the MAC/SAP address information stored in VTAM that is typically associated with the PU is actually the address of the APPN (DLUR) device. Data intended for the PU is sent from the host to the DLUR and it is the responsibility of the DLUR to forward that information to the PU. As a result, the SNA-specific information retrieved from VTAM includes the MAC/SAP address of the APPN DLUR device.
As noted, the DLSw circuit information acquired by the NMS via the SNMP queries includes the MAC/SAP address information of the host and the PU. Yet this DLSw circuit information cannot be directly correlated with the VTAM supplied information because the xe2x80x9cPUxe2x80x9d information differs (the actual PU MAC/SAP information versus the DLUR MAC/SAP information). Moreover, the APPN DLUR device maintains information (such as the PU name) of the PU but it does not recognize the presence of DLSw devices routing session traffic between it and the PU. Therefore, the conventional correlation approach cannot be effectively used to correlate information between SNA/IP segments of a mixed APPN and DLSw network.
The present invention is directed to providing the appropriate tools to draw an SNA session over such a network topology. In particular, the invention provides a method to correlate SNA traffic sessions that traverse both DLSw and APPN devices to enable a complete view of a mixed APPN and DLSw network. More specifically, the present invention is directed to a technique for correlating SNA/IP information within a heterogeneous network having APPN and DLSw routers to enable drawing of a SNA session and diagnosing of problems associated with the session.
The present invention comprises a technique for efficiently correlating information pertaining to entities of a mixed Advanced Peer to Peer Networking (APPN) and Data Link Switching (DLSw) computer network. The entities comprise System Network Architecture (SNA) host mainframe (xe2x80x9chostxe2x80x9d) and physical unit (PU) entities, along with DLSw and APPN/DLSw devices. Broadly stated, the technique involves identifying a SNA session path as using Dependent Logical Unit Requester (DLUR) services of the APPN/DLSw device and thereafter obtaining media access control (MAC)/service access point (SAP) information needed to correlate the SNA session to the DLSw peer devices and an associated DLSw peer circuit connection. A DLSw peer connection is established between the APPN/DLSw device and its remote xe2x80x9cpeerxe2x80x9d DLSw device that comprises DLSw circuits identified by, inter alia, data link identifiers (IDs) comprising attachment addresses of the DLUR and PU entities.
According to the invention, the technique involves determining whether the network includes an APPN device by identifying the PU as xe2x80x9cgoing throughxe2x80x9d a DLUR. A virtual telecommunication access method (VTAM) display of an active PU at a network management station (NMS) indicates whether the device is, e.g., an APPN router performing DLUR services on behalf of the PU. If the network includes such an APPN node, the DLUR name retrieved from VTAM is of the form NETID.CP name. Note that the NMS communicates with the host over a xe2x80x9cpipexe2x80x9d connection to acquire SNA-specific information from a VTAM table structure at the host. The SNA-specific information acquired from VTAM includes, inter alia, (i) the MAC/SAP addresses of the APPN DLUR device; (ii) the DLUR name for the PU, (iii) a control point (CP) name of the PU; and (iv) an ID block number/ID number (IDBLK/IDNUM) of the PU.
Next, the technique determines whether the DLUR device is a manageable router and, if so, correlates the APPN/DLUR name of the router to an Internet Protocol (IP) address. A node is considered manageable if it responds to simple network managment protocol (SNMP) queries from the NMS with requested information using, e.g., an APPN management information base (MIB) query to determine its CP name. Here, the NMS has access to a list of IP addresses of the routers. If the router does not have APPN functionality, it responds negatively to the MIB query; otherwise, the router responds with its NETID.CP name in the APPN MIB. A simple correlation is then performed between the APPN addressing (NETID.CP name) and SNMP addressing (IP address) for that router.
A next step of the inventive technique is to find a logical connection (i.e., a xe2x80x9clink stationxe2x80x9d) between the APPN router and the PU. In accordance with one aspect of the invention, a DLUR MIB may be used to query the DLSw/APPN router. The DLUR MIB includes a field (dlurPuLsName) that identifies the link station for a particular PU that is used to communicate with the DLUR router. If the router does not support the DLUR MIB, the CP name of the PU provided by VTAM may be used as the basis of a query into the APPN MIB (appnLsTable) for a matching CP name (appnLsAdjCpName) associated with the logical link station. If the CP name is not provided, the IDBLK/IDNUM of the PU provided by VTAM may be used to query the appnLsTable to find a matching appnLsPartnerNodeId entry associated with the link station. If the MIBs cannot be used, native device commands (such as router show commands) can be employed to collect this information.
The inventive technique then proceeds to obtain the MAC/SAP address of the APPN link station associated with the PU, which is the remote MAC/SAP address for the DLSw circuit. Preferably, this information is obtained from an APPN MIB. The MAC/SAP address of the APPN router is also obtained from the APPN MIB; this address information is the local MAC/SAP address for the DLSw circuit. The order of the DLSw peer routers is then determined. In the illustrative embodiment, the APPN/DLSw router is the router coupled to the host-side of the network since it identifies the MAC/SAP addresses of its DLUR function as its origin attachment address and the MAC/SAP addresses of the PU as its target attachment address. Furthermore, DLSw router is the router coupled to the remote-side of the network since it identifies the MAC/SAP addresses of the PU as its origin attachment address and the MAC/SAP addresses of the APPN/DLUR as its target attachment address.
Once the order of the DLSw peer routers is determined, the topology of the mixed APPN/DLSw network may be drawn illustrating the relationship between the routers and the SNA entities of the network. Graphical representations of network on the display may include identifying the host-based, APPN/DLSw (DLUR) device with a different icon than the DLSw device. The invention thus allows the NMS to correlate an SNA session over a complex network with a network path that includes DLSw and APPN devices. More specifically, the present invention provides management tools that enable viewing of all segments of the network traversed by the SNA session to thereby enable isolation of a network problem to one of the network segments for a more specialized and targeted diagnosis.